Modern packet-switched networks accommodate a greater number of users and larger amount of traffic than ever before. Unfortunately, the services desired by users now require a much greater amount of bandwidth, while demanding near real-time service in many cases. Consider, for example, a typical user's experience with a mobile phone. While, several years ago, many users were content with voice-only service, many mobile phones now double as personal computers, providing access to streaming video, peer-to-peer applications, and other high bandwidth applications. Furthermore, non-mobile networks have also experienced a significant increase in traffic, as Voice Over Internet Protocol (VoIP), IP Television (IPTV), and similar services have gradually increased in popularity.
Service providers have struggled to keep pace with the ever-increasing bandwidth requirements. Given the significant expenses associated with adding additional equipment, service providers are reluctant to address this problem by simply increasing the capacity of the network. Instead, many service providers desire to decrease costs and simultaneously improve the user's quality of experience by optimizing the efficiency of data transfer over the network.
One such optimization relates to compression of headers associated with packets transferred over the network. In bandwidth-sensitive portions of the network, many service providers employ a header compression algorithm to decrease the amount of data sent over the network. As an example, this header compression may be implemented according to Request For Comments 2507, “IP Header Compression,” published by the Internet Engineering Task Force (IETF). More specifically, during an initialization phase, a node known as a compressor sends a full header including a context identifier, which uniquely identifies the flow associated with the packet. A node known as a decompressor receives the full header and stores the associated context identifier. Subsequently, the compressor may send a “compressed” version of the header, which includes the context identifier, but omits much of the information included in the uncompressed header. Because the decompressor maintains a record of the context identifier and associated header information, the decompressor may reconstruct the uncompressed header rising the information contained in the compressed version.
A second optimization relates to traffic management services implemented by provider edge nodes. In particular, a typical provider edge node implements a service that prioritizes traffic, such that traffic is treated differently depending on a level of service assigned to the traffic. During periods of congestion, the node prioritizes high priority traffic, while temporarily blocking low priority traffic. This technique ensures that the most important traffic reaches its destination by delaying transmission of less important traffic until the congestion subsides.
It would be desirable to implement a network node that performs both header compression and traffic management services. Current solutions, however, fail to concurrently implement both services in a single network node in a manner that achieves the desired benefits of both, while avoiding any potential conflicts. In particular, current solutions fail to resolve the characteristics of the header compression and traffic management functionality, such that each service functions optimally when they are combined.
For the foregoing reasons and for further reasons that will be apparent to those of skill in the art upon reading and understanding this specification, there is a need for a solution that enables implementation of packet header compression in a node including traffic management functionality.